ci: pin pypa/gh-action-pypi-publish to a commit SHA - #11
Merged
Conversation
This workflow referenced the publish action by the floating `release/v1` tag. Every other release pipeline in the org pins a full 40-character commit SHA, so this one could change behaviour with no commit in this repo -- including a change that breaks publishing. That risk is concrete. v1.14.0 bundles twine 6.1.0 and packaging 25.0, which reject Metadata-Version 2.5 -- the version current hatchling emits: InvalidDistribution: Invalid distribution metadata: '2.5' is not a valid metadata version That pin broke the openadapt-evals 0.91.0 release. The tag, the version commit and the GitHub release all landed, then "Publish to PyPI" failed, leaving PyPI stale while every other artifact said the version shipped. Pin v1.14.2 (twine 7.0.0 + packaging 26.2), the version already proven by live uploads of openadapt-privacy 1.0.3 and openadapt-types 0.10.1. Co-Authored-By: Claude Opus 5 <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Problem
This workflow referenced the publish action by the floating
release/v1tag:Every other release pipeline in the org pins a full 40-character commit SHA. A floating tag means upstream can change what runs in a release here with no commit in this repo — including a change that breaks publishing outright.
That risk is not theoretical. v1.14.0 bundles twine 6.1.0 and packaging 25.0, which reject
Metadata-Version: 2.5— the version current hatchling emits:That pin broke the openadapt-evals 0.91.0 release: the tag, the version commit and the GitHub release all landed, then
Publish to PyPIfailed — leaving PyPI stale while every other artifact claimed the version had shipped.Fix
Pin
dc37677b2e1c63e2034f94d8a5b11f265b73ba33(v1.14.2, twine 7.0.0 + packaging 26.2), with a comment recording why.This is not an untested guess. v1.14.2 is the pin already used by OpenAdapt, openadapt-agent, openadapt-capture, openadapt-desktop, openadapt-evals, openadapt-flow and openadapt-tray, and it was just proven end to end by live PyPI uploads of
openadapt-privacy1.0.3 andopenadapt-types0.10.1 — both loggedChecking dist/…: PASSEDon the exact metadata check that v1.14.0 fails.Verification
The tag was resolved against upstream rather than copied:
v1.14.2→dc37677b2e1c63e2034f94d8a5b11f265b73ba33. The workflow still parses as valid YAML.No release is cut
The title is
ci:, andpatch_tagsis["fix", "perf"]— so this merges without cutting a release. That is deliberate: this repo is not currently broken (release/v1floats to a working version today), so there is no failure to prove fixed, and the pin is already validated elsewhere. The new pin takes effect at this repo's next real release.🤖 Generated with Claude Code